Back

@troed We'd also like everything to be open source. But the reality is that even with AGPL, we're still stuck in the pattern that enormous deployments use FOSS Synapse without contributing to its dev/maintenance costs.

Every time an opportunity that we're counting on to fund the team turns around and says "oh, FOSS Synapse is good enough, and we can use it for free, bye" we find ourselves needing to provide a very concrete reason not to freeride - hence Synapse Pro.

@element Do you know of any successful open source businesses that have used this particular method?

"How to make money from FOSS" is an age old problem - but "the free version has a sucky implementation" is, afaik, not the most successful one.

@troed we're not remotely trying to do "the free version has a sucky implementation". FOSS Synapse will keep improving, including perf (but not scalability) work. The model is more like MySQL Enterprise (back int he day). "If you want a massive cluster with a guaranteed SLA, here's our paid clustering product".

@element Right, so let me make a quick rewrite:

"Scaling is hard!

We're seeing many successful Matrix deployments using Synapse for which we are extremely proud and happy. We're also seeing some running into scaling problems as they approach hundreds of thousands of users.

Element is here to help. We're the biggest contributor to the open source Synapse community, and as such we have unparalleled expertise when it comes to optimizing very large deployments. With our performance libraries, that are specifically crafted for Synapse deployments that can reach millions of users, we can get the performance of massive - and costly - server solutions down to something that's much more manageable.

If this is a good fit for your deployment plans, please reach out!"

@troed that is a great pitch - and is fairly close to the original Synapse Pro announcement from https://element.io/blog/synapse-pro-slashes-costs-for-running-nation-scale-matrix-deployments/. The only problem is that then a bunch of big deployments said "that's nice, we'll risk it anyway". Hence the harsher "seriously, you will fail if you try to wing it" wording here.

@element Ok so now I'll need to preface the next part: I am a former Head of SaaS that built a commercial product on top of a FOSS stack. We took the decision, multiple times, which parts to use as-is, which to pay for commercial support and what that cost/benefit looked like.

I'm sorry, you cannot scare potential customers into choosing your Pro product* over the FOSS offering. If they have the budget and their mission is clear, they will pay. If they don't, they'll need to miss their internal targets _before_ they're able to acquire that budget.

The only thing you can do is to wish such a customer good luck, and then sneakily have your sales personnel check in every now and then. If your Pro product is cheaper for their use case, they will come back and pay you once they've figured out they weren't as smart as they hoped.

Now, I asterisked "your Pro product" - because the big difference between your original product announcement and my rewrite is how you phrase Synapse Pro as _a different product_ and not just as paid consultancy/contract to optimize a Synapse deployment. That way you're basically telling your customer they have a one time choice between Pro and Community, and if they choose Community there's no easy "come help us!" path forwards once they run into scaling issues.

I do understand from this communication that things are tight though, and I truly hope that the EU, or individual governments, can finally understand that this is the area in which they should spend money. But, back the original post. As a dev, and former head of blabla, that post really came out as "we made the FOSS version sucky and put the good code into our proprietary product".

fwiw

@troed yup your point makes sense - especially as Synapse Pro very much *is* designed to be dropped into speed up FOSS Synapse when needed. Well, we can always do a 3rd blog post with spin to see how it lands... :)

@teto @troed tl;dr is more "need to be able to keep paying people to work on this".

@teto @troed KDE get 350K EUR/y according to their annual report, which is barely enough to pay for the matrix.org hardware costs, let alone anyone to work on Matrix, unfortunately.

@Tadano @teto @troed @element @skylar it's simple, the entity owns all the copyrights and licenses it under a proprietary license in parallel

@sunweaver @troed the problem is mainly that system integrators turn up saying they can provide that support and sla by using the foss project, and then try to save costs by not working with us as the upstream - meaning the upstream isn’t funded, undermining the underlying project, and increasing the chances of the delivery going wrong without expert support (and with a weakened upstream).

@sunweaver @troed https://www.heise.de/news/Probleme-mit-Open-Source-Videokonferenz-Tool-Hessen-fuehrt-kurzfristig-Webex-ein-10217839.html is one concrete example, which contributed directly to layoffs at Element in 2022 and 2023 as mentioned in https://matrix.org/blog/2022/12/25/the-matrix-holiday-update-2022/. Synapse Pro is an attempt at us giving SIs a much more valuable reason to work with us as the upstream rather than trying to cut us out.

@element @troed The company mentioned in that Heise post is well-known for scrounging in OSS and not giving back much. Been there, seen that.

@alxlg @troed we care, because if the govt’s money goes to an SI rather than us, we can’t pay people to improve or indeed maintain our software…?

@element @troed

Contact the institutions and explain that they need to support your work in addition to their suppliers? It's not like adopters of an innovative decentralized protocol can't understand how much important it is to support its development.

Or adopt Open Nitrate Model? https://www.youtube.com/watch?v=STNomD9GUJY

Going proprietary for the public sector totally defeats the purpose of tech sovereignty and you will have a hard time trying to sell the only viable implementation of a (open) protocol.

@michal FOSS Synapse is the primary project, and is where all new features and maintenance happens. However, it doesn't fund itself, so the cost of also maintaining a paid Rust port of it is worth it if it lets us keep developing and releasing normal Synapse to everyone as FOSS.

@laxla @element Well, this is just like KNX and similar stuff. the Protocol is "Open", but the reference implementation and their docs are paywalled.

@JmbFountain @laxla Synapse isn't a reference implementation (and hasn't been for years), and there are no user-facing features here which are paywalled: just massive clustering. Meanwhile the protocol is @matrix.org and is 100% open, just as ever.

@element

Synapse is just one implementation

Isn't it affiliated with matrix.org? That turns it official (even if it's not associated with the .org directly), with an expectation that it'll remain FOSS.

Element and Synpase are the main Matrix client and server; they're the first in Matrix's implementation list. That creates expectations of officiality.

unless you count huge-footprint elastic scaling as a feature

I do, actually. Scaling is a massively important feature for a social network meant to run government websites.

@laxla

> Isn't it [synapse] affiliated with matrix.org?

Not since 2023, when Element had to stop donating Synapse dev to matrix.org given lack of funding for it: https://element.io/blog/element-to-adopt-agplv3. These days Synapse is just a vendor impl.

> I do, actually. Scaling is a massively important feature for a social network meant to run government websites.

Well, if we had another way to encourage massive Matrix deployments to fund dev, we'd take it.

@element

Not since 2023

Well, I haven't heard about it. Interesting.

Well, if we had another way to encourage massive Matrix deployments to fund dev, we'd take it.

Well, I see two options.

• Become non-profit and offer a 'membership' fee that'll provide branding usage rights. I don't know how fitting this model is for you.
• Offer consulting/installation/pay-for-feature services.

But the paywalling approach is just, why? Like, your corporate/government users have a financial incentive to pay for maintenance anyway, no company is gonna self-install with no warranty whatsoever if they can just not.

This'd be fine if you weren't still the main, semi-official, Matrix quote "vendor".

@laxla

> Become non-profit and offer a 'membership' fee that'll provide branding usage rights.

The Matrix.org Foundation is such a non-profit, selling membership fees (matrix.org/support) - but that didn't generate enough $ at all to fund Synapse dev. Branding rights aren't valuable to commercial deployments, given they typically whitelabel.

@laxla

> Offer consulting/installation/pay-for-feature services.

We have, but one-off gigs are not sustainable and undermine the underlying product work. "Pay for feature" is particularly tricky, because you don't necessarily get to pick the feature, and then have even more features to fund maintenance for. https://speaking.unlockopen.com/nhCZtn/1-billion-dollars-for-open-source-maintainers#sDmtL1I captures the problem well.

@laxla

> Like, your corporate/government users have a financial incentive to pay for maintenance anyway, no company is gonna self-install with no warranty whatsoever if they can just not.

That's what we thought. But what happens is that a big System Integrator turns up to the govt and says "hey, we'll run your Matrix instance for you!", and thinks they can run FOSS and maintain it themselves. Zero $ goes upstream to us, and then you end up with https://www.heise.de/news/Probleme-mit-Open-Source-Videokonferenz-Tool-Hessen-fuehrt-kurzfristig-Webex-ein-10217839.html. And it keeps happening.

@element alright then. It is, however, a dangerous path you're taking. Lots of companies have been through this and lots have gone full corporate.

But, the question that begs to be asked is: how can these SIs approach the government before you do?

@laxla The SIs are often the only ones qualified to sell to the government; they may already be under contract in an existing general purpose agreement, or they meet the necessary size criteria (turnover, # of employees, insurance thresholds). Plus to successfully deliver a huge deployment typically *does* require a SI to do all the glue legwork. But given a chance, it is just too tempting for the SI to save costs by not paying the upstream. So: you have to give them something to pay for.